Information that is transmitted over public networks, including the Internet, often contains confidential and private data. For example, an individual who desires to purchase goods or services in an on-line transaction may be required to transfer funds and/or supply credit card or banking information to the merchant. In addition, authorized senders and recipients may desire to transmit information that is confidential, such as a corporate strategy document, over the Internet. For obvious reasons, this information is extraordinarily tempting to criminals and other eavesdroppers, who may be highly motivated to intercept secret and/or private data.
Due to the nature of the Internet and other public networks, it is impossible to guarantee that only intended recipients will have access to sensitive information. Data transfers are not ordinarily encrypted or scrambled, and eavesdroppers may readily intercept information that is intended only for select individuals or a group of individuals. Thus, unless certain precautions are taken, such as encryption of the data, an individual that uses the Internet or any public network as a transmission medium may risk compromising sensitive information.
In order to reduce this risk, many computer users encrypt data to be transmitted over a network, thereby reducing the risk that an unauthorized listener may intercept and read the data. Encryption is typically accomplished through the use of an appropriate mathematical function to change an intelligible string of numbers into a form that is not easily deciphered. Decryption is accomplished by reversing the process. The encryption and subsequent decryption may be performed through the use of a pair of “keys.” The two keys are related such that one operation, encryption for example, can be performed using one key from the pair, while the reverse transformation can only be computed using the other key in the pair. Unauthorized eavesdroppers that do not have access to the key set used to encrypt and decrypt the information will typically find it infeasible to access the confidential data. The key exchange is thus a critical part of establishing secure communications over a data network.
The computing industry in general, and the Internet Engineering Task Force (IETF) in particular, has adopted security standards and protocols that, when implemented, are useful to encrypt data. In addition, the IETF has established an Internet Protocol Security (IPsec) working group, which has published a number of standards and Requests for Comments (RFCs). These documents provide details as to proposed or de-facto industry standard encryption techniques. This working group has published, among others, the “The Internet Key Exchange (IKE),” by D. Harkins and D. Carrel, RFC-2409, November, 1998, which is incorporated herein by reference.
The IKE protocol was designed to negotiate and provide authenticated keying material for security associations (“SAs”). The IKE protocol, among other things, is particularly useful for the secure exchange of encryption keys between two computers. Keys exchanged through the IKE protocol may be used to subsequently encrypt and decrypt information transmitted between computers over a public or private network.
The IKE protocol adheres to the high-level semantics for key management protocols specified by the Internet Security Association and Key Management Protocol (ISAKMP) and the Internet IP Security Domain of Interpretation (DOI). The IKE protocol is typically implemented on a high-level layer of a suite of network protocol stacks. An application within a network node typically invokes the IKE protocol stack, which subsequently generates a series of well-defined messages. The code that implements the IKE protocol, i.e., the IKE protocol stack, is further responsible for transmitting messages to the intended recipient node. The IKE protocol stack, however, does not implement all of the operations that are necessary to communicate over a network. Instead, like other high-level services and applications, the IKE protocol stack relies on lower-level stacks that implement protocols such as the User Datagram Protocol (UDP) and the Internet Protocol (IP) to facilitate network communications.
All communications over an IP network are accomplished by the transmission and switching of fixed-sized data packets. Depending on the network, the IP protocol stack will transmit a maximum length packet, which length is identified as the Maximum Transmission Unit (MTU). The MTU may be specified for a network or for an application on a network. Some IP networks and applications provide a mechanism for revealing or explicitly providing the MTU, e.g., they will provide an MTU value in response to a query from the transmitting application. In addition, the IP protocol itself includes limited provisions for determining the MTU for a given network or application, which determination is known as MTU discovery. It may not always be possible, however, to determine the MTU for a given network or application. If the MTU is known or discovered, and if data that a user seeks to send over an IP network exceeds the MTU for that network or application, the IP protocol stack will repackage the data into smaller packets that do not exceed the relevant MTU. The step of repackaging is also known as fragmentation. Smaller fragmented data packets that do not exceed the relevant MTU are then transmitted over the network to the intended recipient, where they are subsequently reassembled into the original data.
Like any other data, the information contained within an IKE packet, also known as IKE payloads, may at times exceed the MTU for a given network or application. Thus, an IP protocol stack that is running on an IKE-enabled transmitting application will fragment an IKE payload into a size that does not exceed the MTU. Indeed, the IKE protocol stack does not set a DF (don't fragment) flag that is contained as part of an IKE message. Consequently, the IKE protocol authorizes any IP stack to fragment IKE payloads as appropriate.
In addition, a local IP stack may be unaware of the lowest MTU on a node or link that is downstream of the initiating IKE node. Thus, even though the IP stack of the initiating node may fragment an IKE payload, the resulting fragments still may be too large for certain networks and applications. This condition may cause yet additional fragmentation of the IKE payload.
Fragmentation of the IKE payloads by known techniques, such as those employed by the IP stack, will not reliably transmit IKE messages across a network. This is because ordinary IKE payloads are transmitted according to the UDP protocol, which does not track fragmented IP packets. In addition, many network components, such as Network Address Translators (NATs), also do not track IP fragments. Thus, if any IKE payload fragment is dropped, entire IKE payload will be compromised. As a consequence, the receiving IKE peer will not be able to validate or respond to messages from the transmitting IKE peer.
An intended IKE peer may not receive a transmitted IKE packet for a variety of reasons. For example, problems with the network infrastructure between IKE peers, i.e., cabling problems, data collisions, software difficulties, etc., may cause packets to be dropped on a seemingly random basis. For these types of communication problems, it is possible to retransmit the dropped IKE packets, and thereby achieve a successful message exchange. As another example, certain applications, such as NATs, may have a systemic problem in handling IKE packets. This is because an IP fragment that is associated with an IKE packet may not contain sufficient information to permit the NAT to appropriately format or route data. Many IP fragments ordinarily will not contain port or other state information that the NAT requires to perform address and source translations. Thus, IP fragments may be routinely dropped by certain NATs.
Accordingly, there is a need for an improved method and system for handling data packets created pursuant to the existing IKE protocol. More specifically, there is a need for a system and method to fragment IKE payloads that exceed a given MTU into smaller packets that do not exceed the MTU. The IKE payload fragmentation should be conducted in such a manner that IKE packets may be reassembled at a receiving node.